مفهوم الـ Global Objects في Node.js 💡
.
.
هو إحنا في Node.js بنستخدم window زي ما بنعمل في الـ browser؟
السؤال ده سهل ييجي في بالك أول ما تبدأ تشتغل بـ Node.js، بس الحقيقة لا... مفيش window في Node.
وده بيخلينا نسأل السؤال الأهم:
يعني إيه Global Objects في Node.js؟ وإزاي بنستخدمهم؟
———
🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_node-nodejs-nodejsdeveloper-activity-7340077226333237248-sIRW
🔗 Facebook:
https://www.facebook.com/share/p/19gB4Za3QQ
.
.
هو إحنا في Node.js بنستخدم window زي ما بنعمل في الـ browser؟
السؤال ده سهل ييجي في بالك أول ما تبدأ تشتغل بـ Node.js، بس الحقيقة لا... مفيش window في Node.
وده بيخلينا نسأل السؤال الأهم:
يعني إيه Global Objects في Node.js؟ وإزاي بنستخدمهم؟
———
🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_node-nodejs-nodejsdeveloper-activity-7340077226333237248-sIRW
🔗 Facebook:
https://www.facebook.com/share/p/19gB4Za3QQ
إزاي تتعامل مع الـ State في مشاريع الفرونت إند؟ 💡
.
.
خليني أحكيلك سيناريو بسيط:
أنت شغال على UI لتطبيق إعلانات. في الصفحة الرئيسية فيه زرار بيعرض modal، وفي نفس الوقت فيه قائمة إعلانات بترجع من API، ولما تضغط على إعلان بتروح على صفحة التفاصيل.
دلوقتي الـ modal ده لو تحكمت فيه بـ useState مثلًا في نفس الـ component؟ تمام.
بس الإعلانات؟ محتاج تجيبها من API وتخزنها؟ هتضيفها فين؟
ولو صفحة التفاصيل محتاجة تشوف نفس الداتا؟ هتعمل إيه؟
ولو عندك مستخدم مسجل دخول، ومحتاج كل الصفحات تعرف حالته؟
هنا تبدأ قصة الـ State Management، وتحديدًا:
- هل الداتا دي تبقى locally؟
- ولا تكون في global state؟
ولا تفضل على الـ server وتجيبها كل مرة؟
تعال ندردش شوية عن إزاي تتعامل مع الـ State في مشاريع الفرونت إند...
———
✅ أنواع الـ State اللي ممكن تتعامل معاها:
1- Local State
مثل:
- الـ modal مفتوح ولا مقفول
- الـ tab اللي مفتوح
- الفورم فيه error ولا لا
بتستخدم معاه حاجات زي useState, useReducer, أو حتى useRef.
———
2- Global State
ده اللي بيكون مهم لأكثر من component أو حتى أكتر من صفحة.
مثل:
- بيانات المستخدم بعد ما يعمل تسجيل دخول
- اللغة المختارة
- محتوى الـ shopping cart
ممكن تتعامل معاه باستخدام:
Context API | Redux | Zustand | Jotai
———
3- Server State
يعني داتا راجعة من API وبتتغير دايمًا.
مثل:
- قائمة البوستات اللي بترجع
- الإعلانات
- بيانات المنتج
التعامل معاها الأفضل يتم من خلال:
- React Query
- SWR
- custom hooks using fetch
———
4- URL State
ده زي الـ query params والـ path variables.
مثل:
- ?search=react
- /products/123
بتحتاجه لما الصفحة تكون reactive بناءً على URL.
———
💡 إزاي تقرر تستخدم أي نوع منهم؟
اسأل نفسك 3 أسئلة:
1. الداتا دي مين محتاج يشوفها؟
- لو component واحدة تبقى local
- لو أكثر من component أو أكثر من صفحة تبقى global
2. هل الداتا دي راجعة من السيرفر؟
- لو أيوه تبقى server state
- لو لا يبقى ترجع لإجابة السؤال الأول
3. هل محتاج تعمل caching أو refetching؟
- لو أيوه ممكن تستخدم React Query/SWR
- لو لا يبقى الـ useEffect كفاية
———
✅ شوية نصائح من التجربة:
- بلاش تستعجل وتستخدم Redux، كتير بيستخدموه في حاجات صغيرة جدًا ممكن تتحل بـ Context أو حتى props.
- خلي الداتا اللي بتتغير كتير تفضل على السيرفر، وخلي الـ React Query تمسكها بدل ما تعملها global state manually.
- متخليش كل حاجة global، ده بيخلي الـ re-rendering يزيد والـ debugging بيكون أصعب.
- الـ Server State مش دايمًا محتاج يتحول لـ Global State، الـ React Query مثلًا بيخزنها وبيشاركها بين الـ components تلقائي، من غير ما تدخلها في Redux أو غيره.
- الـ Context ممتاز للحاجات اللي مش بتتغير كتير، زي الـ theme أو اللغة أو المستخدم اللي دخل مرة واحدة وخلاص.
———
اختيارك للـ state له تأثير مباشر على الـ performance، وكمان الـ maintainability، والـ DX بتاعك.
———
وفقكم الله لكل خير 🌿
.
.
خليني أحكيلك سيناريو بسيط:
أنت شغال على UI لتطبيق إعلانات. في الصفحة الرئيسية فيه زرار بيعرض modal، وفي نفس الوقت فيه قائمة إعلانات بترجع من API، ولما تضغط على إعلان بتروح على صفحة التفاصيل.
دلوقتي الـ modal ده لو تحكمت فيه بـ useState مثلًا في نفس الـ component؟ تمام.
بس الإعلانات؟ محتاج تجيبها من API وتخزنها؟ هتضيفها فين؟
ولو صفحة التفاصيل محتاجة تشوف نفس الداتا؟ هتعمل إيه؟
ولو عندك مستخدم مسجل دخول، ومحتاج كل الصفحات تعرف حالته؟
هنا تبدأ قصة الـ State Management، وتحديدًا:
- هل الداتا دي تبقى locally؟
- ولا تكون في global state؟
ولا تفضل على الـ server وتجيبها كل مرة؟
تعال ندردش شوية عن إزاي تتعامل مع الـ State في مشاريع الفرونت إند...
———
✅ أنواع الـ State اللي ممكن تتعامل معاها:
1- Local State
مثل:
- الـ modal مفتوح ولا مقفول
- الـ tab اللي مفتوح
- الفورم فيه error ولا لا
بتستخدم معاه حاجات زي useState, useReducer, أو حتى useRef.
———
2- Global State
ده اللي بيكون مهم لأكثر من component أو حتى أكتر من صفحة.
مثل:
- بيانات المستخدم بعد ما يعمل تسجيل دخول
- اللغة المختارة
- محتوى الـ shopping cart
ممكن تتعامل معاه باستخدام:
Context API | Redux | Zustand | Jotai
———
3- Server State
يعني داتا راجعة من API وبتتغير دايمًا.
مثل:
- قائمة البوستات اللي بترجع
- الإعلانات
- بيانات المنتج
التعامل معاها الأفضل يتم من خلال:
- React Query
- SWR
- custom hooks using fetch
———
4- URL State
ده زي الـ query params والـ path variables.
مثل:
- ?search=react
- /products/123
بتحتاجه لما الصفحة تكون reactive بناءً على URL.
———
💡 إزاي تقرر تستخدم أي نوع منهم؟
اسأل نفسك 3 أسئلة:
1. الداتا دي مين محتاج يشوفها؟
- لو component واحدة تبقى local
- لو أكثر من component أو أكثر من صفحة تبقى global
2. هل الداتا دي راجعة من السيرفر؟
- لو أيوه تبقى server state
- لو لا يبقى ترجع لإجابة السؤال الأول
3. هل محتاج تعمل caching أو refetching؟
- لو أيوه ممكن تستخدم React Query/SWR
- لو لا يبقى الـ useEffect كفاية
———
✅ شوية نصائح من التجربة:
- بلاش تستعجل وتستخدم Redux، كتير بيستخدموه في حاجات صغيرة جدًا ممكن تتحل بـ Context أو حتى props.
- خلي الداتا اللي بتتغير كتير تفضل على السيرفر، وخلي الـ React Query تمسكها بدل ما تعملها global state manually.
- متخليش كل حاجة global، ده بيخلي الـ re-rendering يزيد والـ debugging بيكون أصعب.
- الـ Server State مش دايمًا محتاج يتحول لـ Global State، الـ React Query مثلًا بيخزنها وبيشاركها بين الـ components تلقائي، من غير ما تدخلها في Redux أو غيره.
- الـ Context ممتاز للحاجات اللي مش بتتغير كتير، زي الـ theme أو اللغة أو المستخدم اللي دخل مرة واحدة وخلاص.
———
اختيارك للـ state له تأثير مباشر على الـ performance، وكمان الـ maintainability، والـ DX بتاعك.
———
وفقكم الله لكل خير 🌿